- 7 minutes to read

Prerequisites for the Nodinite Azure Logic Apps Logging and Monitoring Agent

Info

This page is the one home for the prerequisites of the Nodinite Azure Logic Apps Logging and Monitoring Agent, for Logic Apps Monitoring and Logic Apps Logging: supported Logic App types, software, Azure access, Windows and SQL Server rights, and firewall ports. The Install, Configuration, and Troubleshooting pages link here instead of repeating these facts.

Before you enable the built-in Azure Logic Apps diagnostics, read About Logic Apps Logging options to choose your logging approach. Check off each topic:

Verified Topic
How the agent uses Azure
Software Requirements
Azure access: App Registration and roles
Enable Logic Apps Logging in Azure
Windows User Rights
SQL Server rights
Firewall settings

How the agent uses Azure

The agent has two jobs, and they use different Azure services:

  • Monitoring (state of Logic Apps and workflows, Non-Events thresholds, remote actions): the agent calls the Azure REST API through Azure Resource Manager. This needs only an App Registration with the right roles.
  • Logging and failed-run monitoring: every Logic App sends its runtime events through a Diagnostic setting to an Event Hub. The agent reads that stream, keeps its read position (the checkpoint) in a Storage Container, fetches the payloads of matching Actions from the run history through the REST API, and posts Log Events to the Nodinite Log API, for users to search in Log Views.
graph LR subgraph AZ["fa:fa-cloud Azure subscriptions"] LA["fa:fa-sitemap Logic Apps
Consumption and Standard"] DS["fa:fa-sliders Diagnostic setting
WorkflowRuntime"] EH["fa:fa-code-branch Event Hub"] ST["fa:fa-boxes Checkpoint
Storage Container"] ARM["fa:fa-cloud Azure Resource Manager
REST API"] LA --> DS DS -->|Diagnostics| EH ARM --- LA end subgraph NI["fa:fa-server Nodinite"] AG["fa:fa-monitor-waveform Logic Apps agent"] DB["fa:fa-database Agent Database"] LAPI["fa:fa-cloud-arrow-down Log API"] end AG -->|Read stream| EH AG -->|Checkpoint| ST AG -->|Monitoring, payloads, remote actions| ARM AG --- DB AG -->|Log Events| LAPI style EH fill:#3F827B,color:#fff style ST fill:#3F827B,color:#fff style ARM fill:#2678BD,color:#fff style AG fill:#E47528,color:#fff

Diagram: Monitoring uses only the REST API (blue). Logging and failed-run monitoring also need the Event Hub and its checkpoint container (teal). The agent (orange) posts Log Events to the Log API.

Azure services at a glance

Azure service Needed for Required?
App Registration in Microsoft Entra ID Every call the agent makes to Azure ✅ Always
Azure Resource Manager (REST API) Monitoring, remote actions, and fetching payloads from the run history ✅ Always
Diagnostic setting on each Logic App, category WorkflowRuntime, destination Event Hub Logging and failed-run monitoring ✅ For Logging and failed runs
Event Hub Carries the diagnostic stream to the agent ✅ For Logging and failed runs
Storage Container (Blob) Stores the checkpoint; one container per Event Hub ✅ For Logging and failed runs
Log Analytics workspace Not read by Nodinite ❌ Not needed
Application Insights Not read by Nodinite ❌ Not needed
Metrics (AllMetrics in the Diagnostic setting) Not read by Nodinite; only adds Azure cost ❌ Leave disabled

A Diagnostic setting can also send to Log Analytics or a Storage account at the same time; Nodinite ignores those destinations. Reduce Azure Logic Apps Run History Retention to Lower TCO explains why you can usually remove them: Nodinite keeps the long-term history, so Azure needs only a short run-history and Event Hub retention window.

Supported Logic App types

Both hosting models are supported, with the same agent and no separate configuration. They differ in where you add the Diagnostic setting and in which Azure roles apply:

Logic App type Azure resource Where to add the Diagnostic setting Built-in roles for remote actions
✅ Consumption Microsoft.Logic/workflows, one resource per workflow On each workflow (Microsoft guide) Logic App Operator, Logic App Contributor
✅ Standard Microsoft.Web/sites, one Logic App hosting many workflows On the Logic App, covering all its workflows (Microsoft guide) Logic Apps Standard Operator, Logic Apps Standard Contributor

Software Requirements

In Nodinite v7 on Windows Server, the agent is an IIS web site with its own port, installed through the Nodinite Portal. It usually runs on the Nodinite application server, together with the Core Services.

Product Nodinite v7 (IIS web site) Nodinite v6 (Windows Service, ⚠️ Legacy)
Windows Server Windows Server 2025, 2022, or 2019, the same as the Nodinite v7 platform requirement Windows Server 2012 to 2025
IIS IIS with the IIS Windows Features Not used
.NET .NET 10.0 Hosting Bundle (includes the .NET Runtime and the ASP.NET Core Runtime) for agent 7.3.9 and later New 7.3.9 .NET 9.0 for agent versions 6.1.29 to 7.3.8
DacFX DacFX 16.1 or later, to install and update the Agent Database Same
SQL Server A SQL Server instance for the Agent Database Same

Important

The agent follows the Microsoft support policy and gets monthly updates. Patch your .NET environment regularly; see the .NET and .NET Core Support Policy.

Supported Versions

Microsoft deprecates older Azure API versions now and then. Nodinite always supports the APIs that Microsoft supports, so update Nodinite and the agent regularly.

Make sure to subscribe to our Release Notes.

Azure access: App Registration and roles

The agent always authenticates with an App Registration (application and client secret) in Microsoft Entra ID, for every subscription you add. Give it the Azure RBAC roles for the features you use: Reader for monitoring, the Operator or Contributor roles for remote actions, a role with Microsoft.Web/sites/config/list/action for the run history retention of Standard workflows, and Azure Event Hubs Data Receiver and Storage Blob Data Contributor for logging.

Azure Access and Roles → has the role per feature and scope, and the choice between the App Registration and SAS keys for the Event Hub.

Enable Logic Apps Logging in Azure

Logging and failed-run monitoring need three things in Azure: a Diagnostic setting with the WorkflowRuntime category on each Logic App (see Supported Logic App types for where), a dedicated Event Hub in the same region, and one checkpoint Storage Container per Event Hub. The ARM Template scripts it.

Enable Logic Apps Logging in Azure → covers the Event Hub entity, partitions, retention, and why Logic Apps need their own Event Hubs.

What Windows User Rights does the Azure Logic Apps Logging and Monitoring Agent require?

The agent runs under a service identity:

  • Nodinite v7: the IIS application pool identity of the agent web site, set in the Nodinite Portal (Agents step).
  • Nodinite v6 (legacy): the account of the Windows Service.

Use a domain account (preferred) or a local named account, and give it the Log on as a service right; see How to set logon as a Windows service right. The agent needs no Windows rights on other servers: all Azure access goes through the App Registration.

What SQL Server rights does the Azure Logic Apps Logging and Monitoring Agent require?

The agent stores run state, statistics, and resubmit retry counts in its own SQL Server Agent Database. Every agent instance needs its own database.

On the SQL Server instance with the Agent Database, map the service identity to the database as:

  • db_owner: required for both installation and updates, and for runtime. The agent updates the database schema on startup when a new version is deployed.

Tip

For installing the Agent Database manually, connection strings, and troubleshooting, see the Agent Database guide.

What firewall settings does the Azure Logic Apps Logging and Monitoring Agent require?

The agent needs a firewall rule for every hop: the Monitoring Service to the agent port, the agent to the Log API port (both set per environment in the Nodinite Portal), SQL Server on 1433 for the Agent Database, and outbound HTTPS 443 to Microsoft Entra ID, Azure Resource Manager, the run history, and Storage, plus AMQP 5671 and 5672 (or 443) to the Event Hubs. When the agent runs on the Core Services Server, the hops between the Core Services and the agent need no rule.

Firewall Settings → is the one home for this agent's ports: a network diagram and one port table per hop, with DNS, proxy, Azure Relay, and Azure resource firewalls.

Frequently asked questions

Find solutions to common problems and the FAQ in the Troubleshooting guide.

Next Steps